About apache2 vulnerability with apr and apr-utils. How bad is it?

About apache2 vulnerability with apr and apr-utils. How bad is it?

am 11.09.2009 01:05:56 von David Taveras

--001636025af1f549a20473413d37
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I run apache 2.2.9 & apache 2.2.11 both with apr-1.2.11p2 &
apr-util-1.2.10p2


According to the CVE at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2412 only 0.9.x and
1.3.x are affected . Could anybody confirm that this is so? If not.. how
bad is this vulnerability to a user? Would mod_security help for this?

Thank you.

--001636025af1f549a20473413d37
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

I run apache 2.2.9 & apache 2.2.11 both with=A0 apr-1.2.1=
1p2   &=A0 apr-util-1.2.10p2


According to the CVE at href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE- 2009-2412">htt=
p://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2009-2412=A0 only=A0 0=
..9.x and 1.3.x are affected .=A0 Could anybody confirm that this is so? If =
not.. how bad is this vulnerability to a user? Would mod_security help for =
this?


Thank you.




--001636025af1f549a20473413d37--

Re: About apache2 vulnerability with apr and apr-utils.How bad is it?

am 11.09.2009 01:54:57 von wrowe

David Taveras wrote:
>
> I run apache 2.2.9 & apache 2.2.11 both with apr-1.2.11p2 &
> apr-util-1.2.10p2
>
> According to the CVE at
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2412 only 0.9.x
> and 1.3.x are affected . Could anybody confirm that this is so? If
> not.. how bad is this vulnerability to a user? Would mod_security help
> for this?

[cc'ing dev@ to point out this error]

The description of the CVE is wildly wrong.

There is no known exploit of these flaws relative to Apache httpd itself.
The version numbers you reference refer to APR, so this is applicable to
all distributions of httpd 2.x (2.0 included 0.9, 2.2 included 1.3).

Third party modules might be affected; Other projects or products using APR
may be affected; one project is known to be affected.

However, any code which is affected remains vulnerable, in that these
bugs would only be triggered by using untainted/untrusted input as the
memory allocation size. Any affected application would be subject to
memory exhaustion DoS vectors until the code properly detaints the input
which determines the size of memory allocations.

This was granted a CVE strictly on the basis that the effects of the flaw
may unexpectedly be worse than expected; the affected code may unexpectedly
continue, rather than failing or segfaulting as expected, based on design.

Finally, mod_security is very unlikely to have any effect whatsoever on
this group of issues. Input into httpd is already constrained in terms
of size before these calls to APR occur, so this is unlikely to affect
typical httpd modules. Non-HTTP protocols, or HTTP implementations other
than httpd are more likely to be affected, again depending upon the code
used and caution exercised by the developer.


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: About apache2 vulnerability with apr and apr-utils.

am 11.09.2009 03:05:51 von David Taveras

--001636025af1cf926e047342ea6f
Content-Type: text/plain; charset=ISO-8859-1

Hello William.


You mentioned as far as APR causing a DoS, how about the execution of
arbitrary code through apache as the CVE says..?

Thank you

Daniel

On Thu, Sep 10, 2009 at 6:54 PM, William A. Rowe, Jr.
wrote:

> David Taveras wrote:
> >
> > I run apache 2.2.9 & apache 2.2.11 both with apr-1.2.11p2 &
> > apr-util-1.2.10p2
> >
> > According to the CVE at
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2412 only 0.9.x
> > and 1.3.x are affected . Could anybody confirm that this is so? If
> > not.. how bad is this vulnerability to a user? Would mod_security help
> > for this?
>
> [cc'ing dev@ to point out this error]
>
> The description of the CVE is wildly wrong.
>
> There is no known exploit of these flaws relative to Apache httpd itself.
> The version numbers you reference refer to APR, so this is applicable to
> all distributions of httpd 2.x (2.0 included 0.9, 2.2 included 1.3).
>
> Third party modules might be affected; Other projects or products using APR
> may be affected; one project is known to be affected.
>
> However, any code which is affected remains vulnerable, in that these
> bugs would only be triggered by using untainted/untrusted input as the
> memory allocation size. Any affected application would be subject to
> memory exhaustion DoS vectors until the code properly detaints the input
> which determines the size of memory allocations.
>
> This was granted a CVE strictly on the basis that the effects of the flaw
> may unexpectedly be worse than expected; the affected code may unexpectedly
> continue, rather than failing or segfaulting as expected, based on design.
>
> Finally, mod_security is very unlikely to have any effect whatsoever on
> this group of issues. Input into httpd is already constrained in terms
> of size before these calls to APR occur, so this is unlikely to affect
> typical httpd modules. Non-HTTP protocols, or HTTP implementations other
> than httpd are more likely to be affected, again depending upon the code
> used and caution exercised by the developer.
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>

--001636025af1cf926e047342ea6f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello William.


You mentioned as far as APR causing a DoS, how ab=
out the execution of arbitrary code through apache as the CVE says..?
r>Thank you

Daniel

On Thu, Sep 10,=
2009 at 6:54 PM, William A. Rowe, Jr. < lto:wrowe@rowe-clan.net">wrowe@rowe-clan.net> wrote:

204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<=
div class=3D"h5">David Taveras wrote:

>

> I run apache 2.2.9 & apache 2.2.11 both with =A0apr-1.2.11p2 =A0 &=
amp;

> apr-util-1.2.10p2

>

> According to the CVE at

> 12" target=3D"_blank">http://cve.mitre.org/cgi-bin/cvename.cgi?n ame=3DCVE-2=
009-2412
=A0only =A00.9.x

> and 1.3.x are affected . =A0Could anybody confirm that this is so? If<=
br>
> not.. how bad is this vulnerability to a user? Would mod_security help=


> for this?



[cc'ing dev@ to point out this error]



The description of the CVE is wildly wrong.



There is no known exploit of these flaws relative to Apache httpd itself. r>
The version numbers you reference refer to APR, so this is applicable to >
all distributions of httpd 2.x (2.0 included 0.9, 2.2 included 1.3).



Third party modules might be affected; Other projects or products using APR=


may be affected; one project is known to be affected.



However, any code which is affected remains vulnerable, in that these

bugs would only be triggered by using untainted/untrusted input as the

memory allocation size. =A0Any affected application would be subject to

memory exhaustion DoS vectors until the code properly detaints the input >
which determines the size of memory allocations.



This was granted a CVE strictly on the basis that the effects of the flaw r>
may unexpectedly be worse than expected; the affected code may unexpectedly=


continue, rather than failing or segfaulting as expected, based on design.<=
br>


Finally, mod_security is very unlikely to have any effect whatsoever on

this group of issues. =A0Input into httpd is already constrained in terms r>
of size before these calls to APR occur, so this is unlikely to affect

typical httpd modules. =A0Non-HTTP protocols, or HTTP implementations other=


than httpd are more likely to be affected, again depending upon the code >
used and caution exercised by the developer.





------------------------------------------------------------ ---------

The official User-To-User support forum of the Apache HTTP Server Project.<=
br>
See <URL: lank">http://httpd.apache.org/userslist.html> for more info.

To unsubscribe, e-mail: g">users-unsubscribe@httpd.apache.org

=A0 " =A0 from the digest: @httpd.apache.org">users-digest-unsubscribe@httpd.apache.org

For additional commands, e-mail: org">users-help@httpd.apache.org






--001636025af1cf926e047342ea6f--

Re: About apache2 vulnerability with apr and apr-utils. How bad is it?

am 11.09.2009 03:18:29 von wrowe

David Taveras wrote:
>
> You mentioned as far as APR causing a DoS, how about the execution of
> arbitrary code through apache as the CVE says..?

No, you misinterpreted; the application developer must expose a DoS/memory
exhaustion vector; where that exists, and the affected version of APR
is used, and the information written to the never-allocated buffer just
happens to overlap some predictable, current allocations, then the external
user may trigger a segfault but possibly worse, depending ENTIRELY on
the code in the application.

An example is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2411
svn's libsvn_delta library, but there may be other applications in the
wild which suffer similar, lesser or worse side effects from trusting
untained user input.


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: About apache2 vulnerability with apr and apr-utils.

am 14.09.2009 01:29:11 von David Taveras

--00c09fd1aeaca0e9f104737deac0
Content-Type: text/plain; charset=ISO-8859-1

Greetings William,

On Thu, Sep 10, 2009 at 8:18 PM, William A. Rowe, Jr.
wrote:

>
>
> No, you misinterpreted; the application developer must expose a DoS/memory
> exhaustion vector; where that exists, and the affected version of APR
> is used, and the information written to the never-allocated buffer just
> happens to overlap some predictable, current allocations, then the external
> user may trigger a segfault but possibly worse, depending ENTIRELY on
> the code in the application.
>
>
It is to my understanding this is all based on the amount of input and how
it is sanitized. We appreciate if for the sake of the users that cannot
upgrade at this moment you could kindly provide a source or example of what
would constitute an open "DoS/memory
exhaustion vector" so that we may evaluate our code at the instances it
recieves user input. Thank you

David

--00c09fd1aeaca0e9f104737deac0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greetings William,

On Thu, Sep 10, 2009 a=
t 8:18 PM, William A. Rowe, Jr. < we@rowe-clan.net">wrowe@rowe-clan.net> wrote:
class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); m=
argin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">




No, you misinterpreted; the application developer must expose a DoS/m=
emory

exhaustion vector; where that exists, and the affected version of APR

is used, and the information written to the never-allocated buffer just

happens to overlap some predictable, current allocations, then the external=


user may trigger a segfault but possibly worse, depending ENTIRELY on

the code in the application.



It is to my understanding this is all based on t=
he amount of input and how it is sanitized.   We appreciate if for the =
sake of the users that cannot upgrade at this moment you could kindly provi=
de a source or example of what would constitute an open=A0 "DoS/memory=



exhaustion vector" so that we may evaluate our code at the instances i=
t recieves user input. Thank you

David


--00c09fd1aeaca0e9f104737deac0--